Recent technological, economic and regulatory trends in the fields of telephony and data communications have resulted in the need for enhanced network interoperability. Where internetworking is to take place among connection oriented networks which operate using different addressing schemes, for instance a plurality of networks comprised of interconnected private networks or service provider networks, special techniques must usually be deployed in order for a message sent from the originating end system to properly route via the intermediate networks to the destination end system. Traditionally, network interoperability has been achieved by the use of routing tables, to support address relocation across different intermediate network boundaries.
Signalling in connection oriented networks is the process of establishing, maintaining and releasing a message connection through the exchange of connection establishment request and connection establishment acknowledgement messages through the network nodes along a given message path. For signalling purposes, each network node device in a given network may be associated with a routing table or the like which provides internal addressing information for all of the destination addresses that are employed by each of the network users. Generally, it is important to maintain routing tables which are relatively compact in size, in that limited memory may be available to each particular network node device for storage of its associated routing table. In any event, and as explained below, if the routing table must grow substantially as users are added or as the network grows, then this results in complexity which limits the size of the network which can be effectively attained.
Where destination addresses are aggregatable or topologically assigned, such that all addresses which are topologically related to each other can be summarized to a small number of addresses that are typically leading digits or prefixes (for example, addresses which are accessed off the same node), the routing table associated with each of the network node devices of the intermediate networks may be maintained to a manageable size. This is because the network node devices within the intermediate networks can advantageously employ prefix-based routing. However, with the advent of applications in telephony such as local number portability, mobility and customer owned addresses, the size and complexity of routing tables can be expected to increase as more addresses lose their topological significance. Where addresses are no longer assigned topologically, conventional switching systems may no longer scale well to larger and larger address spaces as the number of interworked networks which must be addressed is ever increased. This results from the fact that it would be necessary in such circumstances to have a routing table entry for every destination network node device on the interworked network space.
There are also instances where a given intermediate network, according to current standards and practices, may be unable or unwilling to route directly using the address spaces of other interworked networks. These instances include the implementation of Virtual Private Networks (“VPNs”), the incorporation and management of networks whose address spaces have been structured without considering the addressing scheme of the intermediate network, and the need in a given networking space to support location management for mobile end-user devices. As well, another example which may result in similar addressing problems for an intermediate network occurs in the context of topological reorganization of the address spaces of networks to which the intermediate network is connected. Yet another example involves situations where the addresses used by the networks connected to the intermediate network are not globally unique as is often the case for the previously mentioned VPNs.
As one technique for achieving some degree of network interoperability, it has been known to transport a message address between two networks where it may be used, across a single network where the message address cannot be used. This technique is sometimes known to those skilled in this art as tunnelling or tunnelled signalling. Typically, in tunnelled signalling, a signalling message employs an endpoint message address which is of routing significance to both the originating and destination interworked networks. Prior to a signalling message arriving at the ingress node of the intermediate network through which the signalling message is to be routed, the endpoint address is encapsulated in the signalling message and is thereafter routed to the appropriate egress node of the intermediate network via an intermediate address which is of routing significance to the intermediate network. Upon emerging from the egress node of the intermediate network, for instance at the ingress node of the destination network, the signalling message reverts to the use of the original endpoint message address which retains its routing significance to the destination network. Thus, this signalling technique is known as “tunnelling” since the intermediate network is unaware of the originating and endpoint destination addresses. The intermediate network merely routes these external addresses transparently.
In current ATM signalling standards, various mechanisms for tunnelling have been specified. For instance, such mechanisms are found in the ATM User-Network Interface (“UNI”) Specification Versions 2.0, 3.0 and 4.0, respectively dated June 1992, August 1993 and July 1996, each of which is published by the ATM Forum. These particular standards apply in routing connections between private ATM endpoints identified by NSAP formatted ATM addresses across a public network supporting E.164 ATM addresses. Tunnelled signalling according to these known standards may be supported by the use of an existing message field or Information Element (“IE”) within the message format of a connection establishment request message, for instance a Call SETUP request message. The existing message field in question is known to those skilled in this art as the Called Party Subaddress IE, and this field may be used to store and encapsulate the destination endpoint address to which a message or call is destined to be routed.
By way of example, in signalling a Call SETUP request message, an egress network node device of an intermediate network may temporarily place the destination endpoint address of the called party, also known as the Called Party Number, into the Called Party Subaddress IE of the SETUP request message. That same network node device may then temporarily place the egress endpoint address of the intermediate network into the Called Party Number field of the Call SETUP request message. The Call SETUP request message can thereafter be routed to the egress endpoint address by the intermediate network. When the SETUP request message enters the destination network, the contents of the Called Party Number field, namely the egress endpoint address of the intermediate network, may be discarded. The destination endpoint address is then assigned from the Called Party Subaddress IE to the Called Party Number field. A similar mechanism for tunnelling applies to the originating address, known as the Calling Party Number.
One problem with the foregoing existing solutions for tunnelled signalling is that the substitution of an intermediate network address can only occur once for a given Call SETUP message. Where more than a single intermediate network must be employed to route a message, and those intermediate networks do not share a common addressing space with the originating and destination networks nor with each other, the known tunnelling mechanisms do not permit more than one of such intermediate networks to be traversed. Likewise, where the message addresses associated with the respective address spaces of the intermediate networks are not topologically significant outside of each such address space, more than one intermediate network cannot be traversed pursuant to the known tunnelling techniques described above. Another problem with the known tunnelling techniques is that public networks, such as service provider networks, are not permitted to use the Called Party Subaddress IE or Calling Party Subaddress IE for tunnelling purposes according to current standards. As a result, this mechanism cannot be used in a standards complaint manner for local number portability, mobility and customer owned address applications.
In networks which operate according to a connectionless packet switched data technology, for instance those operating pursuant to IP or IPX signalling protocols, tunnelling has been accomplished by encapsulating the original packet in a new packet which comprises an additional header for routing the packet across the space through which tunnelling occurs. The original packet which is encapsulated within the new packet retains the original header together with its payload of application data. Typically, the intermediate network nodes which handle tunnelled IP packets will only make use of the outermost header in routing any packet through a space being tunnelled. Such known methods of tunnelling in IP and IPX networks are found in the following references: D. Provan, “Tunnelling IPX Traffic through IP Networks”, Document No. RFC 1234 dated Jun. 1, 1991; and W. Simpson, “IP in IP Tunnelling”, Document No. RFC 1853 dated October 1995, each reference being issued by the Internet Engineering Task Force (“IETF”).
Based on the foregoing, there is therefore a need to provide a transport mechanism to permit address tunnelling with multiple levels of mapping in connection oriented networks, namely wherein addresses may tunnel through multiple successive networks having unrelated address spaces. There is also a need to provide such a transport mechanism in a manner that it may be implemented in service provider networks and private networks at the same time and without ambiguity. Lastly, there is a need to provide a mechanism for address tunnelling which may be implemented either at the egress point of the preceding network or at the ingress point of the succeeding network. It is an object of the present invention to attempt to meet these varied needs with a generic transport mechanism which permits different network node addresses to be used across multiple network boundaries, as explained in greater detail below.